System and method for fast relay for bandwidth allocation signaling

ABSTRACT

A system and method for optimizing the end-to-end latency transfer rates over an air interface employing a Multi-hop Relays (MHR). The present system and method provides fast signaling process when no Downlink/Uplink Bandwidth allocation changes are employed, thereby bypassing PHY/MAC/IP Stack processing. The solution is intended for the new generation of 5G millimeter band multi-hop relays.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 62/249,431 (hereinafter “431 provisional”), filed 2 Nov. 2015,incorporated herein by reference.

BACKGROUND

Wireless relays are infrastructure devices intended for eitherincreasing the user experience in intra-cell coverage holes or forextending the cell coverage. For mobile wireless applications, acomplete standardized solution was provided by WiMAX (IEEE802.16-2009)while 3GPP LTE provided a solution (TS 36.116) not pursued commercially.These solutions were particularly designed for their specific RadioAccess Network (RAN) solutions.

While the lower frequency bands (≦5 GHz) exhibit better non-line ofsight (NLOS) propagation performance, the poorer diffraction spread forcm/mm waves (≧20 GHz) causes much higher propagation losses in NLOSscenarios than the lower bands. Since this confines the use cases forcm/mm bands to mostly line of sight (LOS) propagation cases, providingadditional intra or extra cell coverage requires specifying dedicatedmulti-hop radio relays for the ≧20 GHz bands.

SUMMARY OF THE INVENTION

This solution provides a fast signaling algorithm when no DL/UL BWallocation changes are employed, thus bypassing PHY/MAC/IP Stackprocessing thus decreasing the related control and user latency times.The solution is intended for the new generation of 5G mm band multi-hoprelays. This invention generally refers to 5G, but one skilled in theart will recognize that the solution may be applied to other bands aswell. This solution also proposes idle and wake-up algorithms for 5Gmulti-hop relays.

In an embodiment fast downlink bandwidth allocation system is configuredwith a first level hierarchical device in a multi-hop relay hierarchicalnetwork formed of at least a first, second, and third level node. Thefast downlink bandwidth allocation system is configured to include atleast a non-transitory memory, an uplink bandwidth module, a PHY module,a scheduler, and a processor. The non-transitory memory is configured tostore an allocation data, a first uplink fast feedback data (UFFD)associated with a previous data frame, and an uplink bandwidthallocation request data. The uplink bandwidth module is configured forprocessing the uplink bandwidth allocation request data to produce aprocessed uplink bandwidth allocation data which is written to theallocation data in the non-transitory memory. The PHY module isconfigured to provide conditional instructions to the uplink bandwidthmodule to decode the uplink bandwidth allocation request. The scheduleris configured to schedule bandwidth allocation for the second and thirdlevel nodes based on the allocation data. The processor is incommunication with the non-transitory memory, the uplink bandwidthmodule, the PHY module, and the scheduler for cooperating in bandwidthallocation computational processes. Cooperatively, these componentsimplement the fast downlink bandwidth allocation method, whichconditionally bypass decoding bandwidth allocation data andadvantageously transmits previously decoded bandwidth allocation data,thereby reducing processing latency.

In an embodiment, the present method manages the fast downlink bandwidthallocation in a multi-hop relay hierarchical network. This methodaccesses a first downlink fast feedback data (DFFD) stored in anon-transitory memory and associated with a previous bandwidthallocation data from a previous data frame. Furthermore, the presentmethod receives an encoded downlink bandwidth allocation data associatedwith the current frame from a master multi-hop relay and a second DFFDassociated with the current frame from a master multi-hop relay. Thesecond DFFD associated with the current data frame is accessed andcompared with the first DFFD to determine a difference between thecurrent and the previous downlink bandwidth allocation data. Based on adetermination that there is no difference between the first and secondDFFD, the method may then skip processing/decoding the encoded downlinkbandwidth allocation data and transmit the bandwidth allocation data asper a previous frame. Alternatively, if the method determines that thereis that a difference between the first and second DFFD, the methoddecodes the encoded downlink bandwidth allocation data and transmits thedecoded bandwidth allocation data to one or more third level nodes.

In another embodiment, a fast downlink bandwidth allocation systemconfigured with a second level node in a multi-hop relay hierarchicalnetwork formed of at least a first, second, and third level node isemployed. Such a system includes a non-transitory memory, a downlinkbandwidth module, a PHY module, a scheduler, and a processor. Thenon-transitory memory is configured to store a bandwidth allocationdata, a received bandwidth allocation data, and a first downlink fastfeedback data (DFFD) associated with a previous data frame. The downlinkbandwidth module is configured to process the received bandwidthallocation data to produce a processed bandwidth allocation data whichis written to the bandwidth allocation data in the non-transitorymemory. The PHY module is configured to provide conditional instructionsto the downlink bandwidth module related to processing the receivedbandwidth allocation data. The scheduler is configured to schedulebandwidth allocations for at least the third level nodes based on thebandwidth allocation data. The processor is in communication with thenon-transitory memory, the downlink bandwidth module, the PHY module,and the scheduler for cooperating in bandwidth allocation computationalprocesses.

BRIEF DESCRIPTION OF THE INVENTION

FIG. 1 shows one multi-hop relay (MHR) network architecture, in anembodiment.

FIG. 2A shows one slave MHR latency optimization, in an embodiment.

FIG. 2B shows exemplary system for processing downlink bandwidthallocation, in an embodiment.

FIG. 2C shows exemplary system for processing uplink bandwidthallocation requests, in an embodiment.

FIG. 3 shows one downlink allocation monitoring process in an exemplarydownlink look up table implementation, in an embodiment.

FIG. 4 is a flowchart illustrating one exemplary method for slave MHRdownlink bandwidth (DL BW) allocation, in an embodiment.

FIG. 5 is a flowchart illustrating one exemplary method for slave MHRuplink bandwidth (UL BW) allocation feedback, in an embodiment.

FIG. 6 shows one exemplary data frame transmission structure utilizing aZadoff-Chu implementation, in an embodiment.

DETAILED DESCRIPTION OF THE FIGURES

The following are acronyms and abbreviations for the associated phrases,which are used in the present application:

-   -   FAS—Fog Access Server    -   HFC—Hybrid Fiber-Coax    -   LTE—Long Term Evolution    -   MHRR—Multi-Hop Radio Relay    -   MTC—Machine Type Communications    -   M2M—Machine-to-Machine Communication    -   RAN—Radio Access Network    -   RU—Radio Unit

5th generation wireless system (5G) radio links are expected to supportone gigabits per second (Gbps) or more on-demand end-user data rates.This will require large bandwidth support, currently only available inthe centimeter/millimeter (mm) bands, for example, from 20-100 GHz orhigher. In addition, 5G radio links are also expected to support verylow transfer latencies optimizing the end to end latency. This may beaccomplished by employing fast transfer radio relays with optimizedlatency times.

The present system and method present low latency transfer optimizationsby optimizing the end-to-end latency transfer rates over a Multi-HopRelay (MHR) air interface by tracking changes to each users downlinkbandwidth allocation. In one embodiment, the present system and methodemploys a logical downlink lookup table backed by a Physical FastSignaling Channel (PFSCh) and a new logical uplink feedback table backedby a Physical UL Bandwidth Feedback Channel (PUBFCh). As compared to theprior art techniques the optimizations disclosed herein provide improvedefficiency for long packets transmitted over the air, one non-limitingexample is streaming of video data.

The following description utilized the terms “slave” or “a slave” and“slave to,” and correspondingly “master” to describe the relationshipbetween devices in the hierarchical communication structures describedherein, all of which reflects the direction of user data transmission.One example of a hierarchical structure that may be utilized in thepresent system is as follows from the highest position in thehierarchical structure to lowest: Master MHR, slave MHR, pico-basestation (pBS), and remote unit (RU). By way of example, a slave MHRdevice is slave to a master MHR device, a pBS device is slave to a slaveMHR device, and a RU is slave to a pBS. Furthermore, any device lower inthe hierarchical structure may be slave to any device higher in thestructure, e.g., a RU may be slave to a slave MHR or a master MHR. Otherhierarchical structures may be utilized and/or more or fewer devices maybe included into a hierarchical structure utilized by the presentinvention without departing from the scope here.

FIG. 1 shows a MHR network 100 architecture. In the embodiment of FIG.1, network 100 is a low-latency fronthaul network that provides, forexample, up to 40 Gbps over the air utilizing millimeter (mm) wave bandsNetwork 100 includes a master MHR 102 and a slave MHR 104. MHR 102 is incommunication with a high capacity 10/40 Gbps Passive Optical Network(PON) 101. Other high capacity data networks may be utilized withoutdeparting from the scope herein. Each MHR 102, 104 is in wirelesscommunication with each other, one or more base stations, shown in theembodiment of FIG. 1 as pico-base stations (pBS) 106-110, and aplurality of radio units (RUs) 150-159. Master MHR 102 provides wirelessservices to RU 150 via a 1-3 Gbps signal and RU 151 via a 2-4 Gbpsconnection, pBS 106 via a 10 Gbps connection, and slave MHR 104 via a10-20 Gbps connection. pBS 106 is in wireless communication with RU 152via a 2-4 Gbps signal and RUs 153-154 via 1-3 Gbps signals. Hence,master MHR 102 may provide converged access/fronthauling services. SlaveMHR 104 is in wireless communication with pBS 108 and 110 via a 5-10Gbps connection and RU 155 via a 1-2 Gbps connection. pBS 108 is inwireless communication with RU 156 via a 1-2 Gbps connection and RU 157via a 2-4 Gbps connection. pBS 110 is in wireless communication with RU158 via a 2-4 Gbps connection and RU 159 via a 1-3 Gbps connection. Itwill be understood by one skilled in the art that data rates, number andtype of connections, and number of connected devices presented in FIG. 1are for descriptive purposes only and other implementations may berealized without departing from the scope herein. It will also beunderstood by the skilled artisan that data rates may vary dependent on,e.g., end user data requirements. Network 100 may include more or fewerMHRs (masters and slaves), pBS, RU, and/or other devices notspecifically disclosed here and/or lower and higher throughput rateswithout departing from the scope herein or affecting the generality ofthe concept. It will be understood that pBSs 106-110 are merelyexemplary of any small cell base station and one skilled in the art willunderstand that a pBSs 106-110 may be preplaced with other basestations, such as but not limited to femtocell base stations, microcellbase stations, Home Node B, Wi-Fi components, and systems configured tointerface using GSM, CDMA2000, TD-SCDMA, W-CDMA, LTE, and WiMax.

In a MHR network, like that of network 100, clusters of small cells areserviced by multi-hop relays (MHR). By way of example, pBS 106 and RUs152-154 are serviced by master MHR 102 and pBS 108 and RUs 156-157 areserviced by slave MHC 104. In different embodiment, multi-hop relays mayservice other hierarchical MHR and/or pBS slaves, and may directlyservice RUs. The skilled artisan will recognize this type of service asa convergent access and distribution wireless service. The access methoddescribed herein is considered a fronthaul type of traffic as opposed tothe passive optical network (PON) backhaul services.

In an embodiment concerned with user data latency in a MHR networkarchitecture the number of hierarchical hops utilized to traverse thenetwork may be limited, for example, to less than or equal to 2 hops,for example, from a MHR to a pBS. Direct distribution to RUs, e.g., RUs156-157, are not considered hops when discussing the traverse of a MHRnetwork. For example, data transmitted to RU 157 that data's first hopis from master MHR 102 to slave MHR 104 and its second hop is from slaveMHR 104 to pBS 108. From pBS 108 data is distributed utilizing knowntechniques to RU 157. In another example, data transmitted to RU 155only requires a single hop, that is, from master MHR 102 to slave MHR104. From slave MHR 104 data is distributed utilizing known techniquesto RU 155.

It will be understood by the skilled artisan that MHR networks, likenetwork 100, may be implemented employing suitable space diversitymethods as a hybrid beam-forming/MIMO for over the air trafficimproving, for example, both 10+ Gbps throughput and coverage both inline of sight (LOS) and non-line of sight (NLOS) cases.

In the embodiment of FIG. 1, a millimeter wave band network may beconfigured and arranged as a convergent fronthaul/access capability MHRnetwork. Such a convergent MHR network may support high throughputremote units, for example, remote units having 1-5 Gbps speeds andmulti-hop relays that provide over the air fronthaul capability, such as10-20 Gbps capacity shown between MHR 102 and MHR 104.

One problem in such a convergent MHR network is delays associated withone or more of the PHY, MAC, and IP layers. Optimizing MHR processing atthese layers can beneficially reduce latency to, for example, betweenone (1) and five (5) milliseconds. Solutions to this problem arepresented below.

FIG. 2A shows a system 200 utilized in optimizing network 100 latency.System 200 is shown with master MHR 102 and slave MHR 104 of FIG. 1. Theprinciple of operation utilizes a downlink control channel 206 and anuplink control channel 216 to reduce latency within network 100.

The downlink control channel 206 includes a Downlink Fast SignalingControl Channel (DFSCCh) 202 and a PHY DFSCCh (PDFSCCh) 204. DFSCCh 202is a logical (i.e., MAC Channel) downlink supporting logicalcommunication flow between master MHR 102 to slave MHR 104. PDFSCCh 204is a downlink support PHY control channel for transporting MAC data

The uplink control channel 216 includes a PHY UL Fast Feedback ControlChannel (PUFFCCh) 212 and an UL Fast Feedback Control Channel (UFFCCh)214. PUFFCCh 212 is a logical uplink slave MHR 104 to master MHR 102control channel. UFFCCh 214 is a logical uplink slave MHR to master MHRcontrol channel. PUFFCCh 212 is the supporting PHY transport controlchannel.

DFSCCh 202 and PDFSCCh 204 are shown including data 250 and 252. Data250 is the received downlink and uplink bandwidth allocation data.Downlink fast feedback data 252 (also called herein “DFFD 252” or “data252”) is fast signaling downlink PHY resource allocation data, whichquickly conveys information regarding any change in one or both of thedownlink or uplink bandwidth allocation data. That is, DFFD 252 onlyindicates if a change has occurred, not what that change is. Toaccomplish fast signaling to reduce latency a receiving device firstprocess DFFD 252 to determine if a change has occurred to bandwidthallocations. If no change has occurred the receiving device utilizes thesame bandwidth allocation as used in the previous frame, thuseliminating the need to process data 250. If a change has occurred thereceiving device only then will processes data 250. For more details seeFIG. 2B and the associated description. DFFD 252 may be transmitted in,for example, hexadecimal format as shown in Table 1, below. Uplink fastfeedback data 282 may be transmitted in, for example, hexadecimal formatas shown in Table 3, below.

UFFCCh 214 and PUFFCCh 212 are shown including uplink bandwidthallocation request data 280 and uplink fast feedback data 282 (alsocalled here “UFFD 282” or “data 282”). Data 280 and data 282 representcontrol information. UFFD 282 contains data directed to identifyingchanges in UL bandwidth allocation requests. Data 280 contains all ULbandwidth allocation data for a given receiving device. UFFD 282 may beprocess first to determine if data 280 should be decoded/processed. IfUFFD 282 shows no change to UL bandwidth allocation request since thelast frame, data 280 can be ignored and the receiving device mayallocate bandwidth as per the previous frame. In one example, toaccomplish fast signaling to reduce latency a master MHR 102 firstprocess data 282 to determine if a change has occurred to UL bandwidthallocation requests from slave MHR 104. If master MHR 102 processes data282 and determines no changes to the UL bandwidth allocation request hasoccurred then master MHR 102 utilizes the same UL bandwidth allocationas utilized in the previous frame, and processing of data 280 does notoccur Eliminating the processing of data 280 reduces latency within thesystem. If master MHR 102 determines a change in the UL bandwidthallocation request has occurred then master MHR 102 processes data 280.For more details see FIG. 2C and the associated description.

In an alternative embodiment only data 280 is present. If there is achange to the UL bandwidth allocation request then data 280 is sent, forexample, from slave MHR 104 to master MHR 102. If no change isrequested, then no data is sent. Thus if master MHR 102 does not receivea new UL bandwidth allocation request, then master MHR 102 utilizes thesame UL bandwidth allocation utilized in the previous frame.

Master MHR 102 transmits bandwidth allocation data, for example fastcontrol/signaling data as shown in is FIG. 3, via downlink controlchannel 206. Processing of transmitted downlink control channel 206 maybe handled by a downlink bandwidth allocation monitoring scheme, oneexample of which is method 400 of FIG. 4, below. The downlink bandwidthallocation monitoring scheme monitors and generates data associated withchanges in user downlink bandwidth allocation on a frame by frame basis.In an embodiment, this data is stored in a quickly accessible format,such as a downlink lookup table which is transmitted by master MHR 102via PDFSCCh 204 to the slave MHR 104. The examples that follow arediscussed utilizing a Downlink PHY resource allocation data (e.g., seeTable 1, below, and Downlink PHY resource allocation data 300, FIG. 3).In the present embodiment Downlink PHY resource allocation tables aretransmitted over the logical PHY Fast Signaling Control Channel(PFSCCh). One skilled in the art will appreciate that Downlink PHYresource allocation tables are not that only manner in which this datacan be transmitted and that other systems, data structures, and processmay be utilized without departing from the scope here.

DFSCCh 202 and its transport channel PDFSCCh 204 form a downlink controlchannel 206. Downlink control channel 206 communicates with slave MHR104 any changes that occur in the downlink bandwidth allocation viaDownlink PHY resource allocation tables. Downlink control channel 206signal may be, for example, on a frame-by-frame and/or user-by-userbasis. See FIG. 4 and its associated description for more detail.

In an embodiment, DFSCCh 202 is signaled via a fast PHY/RF channel whichbenefits from not requiring processing MAC and the related IP Stackdata. Thus when there are no changes in the downlink bandwidthallocation from one frame to the next, fast processing of the downlinkbandwidth allocations may be used to reduce the end-to-end latency time.

Regarding communication in the uplink (UL) direction, slave MHR 104signals to master MHR 102 any changes to the UL bandwidth allocationsvia an uplink channel 216, e.g., a pair of PHY/MAC channels. In theembodiment shown in FIG. 2, the pair of PHY/MAC channels are PUFFCCh 212and UFFCCh 214.

UFFCCh 214 processes and hands-off MAC layer UL bandwidth allocationsdata to the PHY layer, where PUFFCCh 212 processes the UL bandwidthallocations for transmission to master MHR 102. If there are no changesto the UL bandwidth allocations in the next data frame then master MHR102 allocates UL data as per the previous frame. Else, if slave MHR 104sends a new UL PHY resource allocation via the pair of PHY/MAC channelsthen master MHR 102 processes the change in the PHY UL allocations.Processing the change in the new PHY UL allocations include at leastupdating the DL bandwidth allocation for transmission to one or morenodes lower in the hierarchical structure, for example, slave MHR 104.

FIG. 2B shows exemplary system 200B for processing downlink bandwidthallocation. System 200B includes master MHR 102 and slave MHR 104 incommunication with one another, and RU 155, pBS 108 and pBS 110 incommunication with slave MHR 104. Slave MHR 104 includes a memory 220,and a processor 222 in communication with a PHY module 224, a DL BWmodule 226, and a scheduler 228. Master MHR 102 includes data 250 anddata 252 as described in FIG. 2A. Master MHR 102 transmits data 250 anddata 252 to slave MHR 104, which stores data 250 and data 252 in memory220. Memory 220 also contains old downlink fast feedback data (DFFD) 251and bandwidth allocation data 260. PHY module 224 processes data 252 todetermine if bandwidth allocation data 260 needs to be updated. In anembodiment, PHY module 224 executes a comparator 253 to compare data 251and data 252. If comparator 253 determines that there is a differencebetween the old bandwidth fast feedback data 251 and the downlink fastfeedback data 252, then PHY module determines that bandwidth allocationdata 260 needs updated. If comparator 253 determines that there is nodifference between the old bandwidth fast feedback data 251 and thedownlink fast feedback data 252, then PHY module determines thatbandwidth allocation data 260 does not need to be updated.

If PHY module 224 determines that bandwidth allocation data 260 does notneed updated then data 250 is not processed and scheduler 228 executesbandwidth allocation as pre the previous frame, that is, as contained inunaltered bandwidth allocation data 260. If, when processing data 252,PHY module 224 determines that there is a change to the downlinkbandwidth allocation then DL BW module 226 processes data 250, producinga processed bandwidth allocation data 270 for updating bandwidthallocation data 260 in memory 220. Updated data 260 is then utilized byscheduler 228 to allocated new downlink bandwidth allocations to RU 155,pBS 108, and pBS 110.

FIG. 2C shows exemplary system 200C for processing uplink bandwidthallocation requests. System 200C includes master MHR 102 and slave MHR104 in communication with one another, and RU 155, pBS 108, and pBS 110in communication with slave MHR 104. Slave MHR 104 is shown includingmemory 220 which stores data 280 and 282 as described in FIG. 2A and avariable sized software buffer 238 storing uplink bandwidth allocationrequest data 239. Master MHR 102 includes a memory 240, and a processor242 in communication with a PHY module 244, a UL BW module 246, and ascheduler 248.

RU 155, pBS 108, and pBS 110 transmit UL bandwidth allocation requeststo slave MHR 104, which are first stored in software buffer 238 as data239. In an embodiment, software buffer 238 changes size to accommodatethe size of data stored therein. Data 239 is then process to generatedata 280 and 282. Slave MHR 104 then produces data 282 which details anychanges in the current UL bandwidth allocation requests from theprevious UL bandwidth allocation requests. Slave MHR 104 transmits data280 and data 282 to master MHR 102, which stores data 280 and data 282in memory 240. Memory 240 also contains UL bandwidth allocation data 290and old UFFD 281. PHY module 244 is shown to include a copy of data 282,a copy of old UFFD 281, and a comparator 283. PHY module 244 processesdata 282 to determine if UL bandwidth allocation data 290 needs to beupdated, that is, if there is a change in the current UL bandwidthallocation request, stored as data 282, as compared to the previous ULbandwidth allocation request, stored as an old UFFD 281. In theembodiment of FIG. 2C, processing data 282 to determine if UL bandwidthallocation data 290 needs to be updated is accomplished by utilizingcomparator 283 to compare old UFFD 281 with data 282 to determine ifthere is a difference between the two. If PHY module 244 determines thatUL bandwidth allocation data 290 does not need updated then data 280 isignored and scheduler 248 executes UL bandwidth allocation as per theprevious frame, that is, as contained in data 290. If, when processingdata 282, PHY module 244 determines that there is a change to the uplinkbandwidth allocation request then UL BW module 246 processes data 280,which produces processed UL bandwidth data for updating allocation data290. Updated data 290 is then utilized by scheduler 248 to allocated newdownlink bandwidth allocations.

FIG. 3 shows downlink PHY resource allocation data 300, which isrepresented as a data structure for storing downlink data in memory forquick access. Data 300 shows one representation of data contained in oras a source for data 252 of FIGS. 2A and 2B. Also shown in FIG. 3 is therelationship between downlink PHY resource allocation data 300 and dataframes 350. Data frames 350 show the result of allocated downlinkbandwidth, which is communicated by, for example, data 250 of FIGS. 2Aand 2B.

Data frames 350 are shown to include five frames, frame (k) 352 throughframe (k+4) 360. Frame (k) 352 includes data bandwidth allocations foruser 01 and user 02; frame (k+1) 354 includes data bandwidth allocationsfor user 03, user 04, and user 02; frame (k+2) 356 includes databandwidth allocations for user 03, user 04, and user 02 (same as theprevious frame, frame (k+1)); frame (k+3) 358 includes data bandwidthallocations for user 01, user 03, user 04, and user 02; and frame (k+2)356 includes data bandwidth allocations for user 03, user 04, and user02. The amount of bandwidth allocation provided to users 03, 04, and 02in frames (k+1) and (k+2) are of the same size, while the amount ofbandwidth allocation provided to users 03, 04, and 02 in frame (k+4) isof a different size as compared to that of frames (k+1) and (k+2), thatis, the same users are allocated bandwidth, but the amount of bandwidthis different. For example, the amount of bandwidth allocated to user 03in frame (k+4) is much large than that provided to user 03 in frame(k+1) and (k+2).

Downlink PHY resource allocation data 300 is formed of columns 302-308associated with data frames 352-360 and rows associated with users. Inthe example of FIG. 3 only five columns 302-310 related to data frames(k) 352 through (k+4) 360, and four users, user 01 through user 04, areshown. More or fewer data frame related columns and users may beincluded in a downlink PHY resource allocation table without departingfrom the scope herein. Examples of users 01-04 are RUs 152, 153, 154,and User 04 (not shown) of FIG. 1 for which DL bandwidth was allocatedfrom pBS 106 as instructed by master MHR 102.

Downlink PHY resource allocation data 300 is utilized, for example byslave pBS 106, to determine if a change has occurred in any of user01-04's downlink bandwidth allocations compared with, for example, theprevious frame. All of the following examples are described utilizingthe comparison of a current frame with a frame immediately preceding it.It will be understood by the skilled artesian that a downlink PHYresource allocation table, like downlink PHY resource allocation data300, may be used in the comparison of a current frame to any one of theprevious frame for purposes of reducing data access time, processingtime, and/or latency.

One or more embodiments may use semi-persistent PHY allocations whichcould employ PHY resource allocation changes using as a reference one ormore frames prior to the current frame.

In another embodiment the system saves a plurality of previous processeddownlink bandwidth allocations to memory and associated each to itsrespective frame. As such, the system may provide a comparison not onlyto the immediately preceding frame but to any of or all of the pluralityof preceding frames with data saved to memory to identify a previouslyprocessed downlink bandwidth allocation that is the same as required bythe current frame. Such as system may advantageously reduce processingtime and latency. In addition, such a system may reduce an amount ofsupporting control information, for example, in the embodiments thatutilize semi-persistent PHY resources allocations for specific types oftraffic. One example of a specific type of traffic includes but is notlimited to VoIP traffic.

Data contained in data fields of data 320 are the results ofcomparisons, on a user by user basis, of downlink bandwidth allocationsfor a first frame and a second frame immediately preceding the firstframe. Entries in the data fields of data 320 may be, for example, azero (0) or a one (1). A zero (0) in a data field represents no changein a user's downlink bandwidth allocation for a given frame as comparedthe frame immediately preceding it. As such the same bandwidthallocation may be reused without further processing. A one (1) in a datafield represents a change has occurred in a user's downlink bandwidthallocation for a given frame as compared the frame immediately precedingit. As such, the slave will process the received downlink IP stackreceived from the master, and execute the required new time/dataallocation requests. This is a time consuming process and advantageouslyavoid by the present system and method's recycling of previous downlinkbandwidth allocations when the present system and method has determinedno changes have been made to the downlink bandwidth allocations since,for example, the previous frame. In an example of user 04, the result ofa comparison of frame (k+2) 356 and previous frame (k+1) 354 produces inthe entry in data field 330 in data 300, which is zero (0) indicating nochange in bandwidth allocation for user 04 as compared to previous frame(k+1). This informs the system that no change has occurred in thedownlink bandwidth allocation since the last frame, such that thedownlink bandwidth allocation used in frame (k+1) 354 may be used againin frame (k+2) 356 thereby reducing processing time and latency. Inanother example looking at user 01, the result of a comparison of frame(k+4) 360 and frame (k+3) 358 produces the entry of one (1) in datafield 332 of data 300. This informs the system that a change hasoccurred in the downlink bandwidth allocation since the last frame suchthat the new downlink bandwidth allocation must be used in frame (k+4)360. Preparing a new downlink bandwidth allocation utilizes a multistepprocess, one example of which is described in see FIG. 4 and itsassociated description, that requires processing time and adds tolatency as compared to there being no change in downlink bandwidthallocation.

In an embodiment, MHRs service up to 16 or 32 high capacity users at ≧1Gbps. Without losing the generality, more or fewer users may beserviced, usually allocated in binary multiples.

FIG. 4 shows a MHR DL BW allocation process, method 400, for example,implemented by slave MHR 104 of FIG. 1. Method 400 minimizes downlinkprocessing latencies when no new downlink time PHY resource allocationsare required.

In step 402 of method 400, MHR's are activated and one or more slaveMHRs are linked to a master MHR wirelessly. In the example of network100, slave MHR 104 is associated with master MHR 102 via a wirelesslink.

In step 404 of method 400, following the reception of the PDFSCCh, anupdate of downlink bandwidth allocation data is initiated. Also, if itis not already active, a scheduler is started for scheduling datatransmissions from slave MHR to each of its associated wirelesslyconnected devices. One example of step 404 is master MHR 102 and slaveMHR 104 coordinating for a transmission of downlink bandwidth allocationevery transmission cycle and slave MHR 104 updating, on a frame by framebasis, its schedule in preparation for receiving at least downlinkbandwidth allocation data.

In step 406 of method 400, slave MHR decodes PDFSCCh, containing dataassociated with downlink bandwidth allocations. This may be the downlinkbandwidth allocation data itself or data generated based on the downlinkbandwidth allocation data indicating any change in the DL BW allocationof the previous frame or, in some embodiments, previous frames. Oneexample of data generated based on the downlink bandwidth allocationdata can be seen in FIG. 3, which shows one exemplary downlink bandwidthlookup table, and in Table 1, below. In one example of step 406, slaveMHR 104 accesses a downlink control channel which includes informationconcerning the lookup table which is updated and transmitted by thehierarchical MHR, on a frame by frame basis at least when one or morechanges to the downlink bandwidth allocation have occurred.

In decision step 408 method 400 utilizes data received and processed instep 404 to determine if changes have occurred in downlink bandwidthallocations.

If in step 408 method 400 determines that changes to the downlinkbandwidth allocation have occurred on a frame-by-frame basis thendecision step 408 moves to step 410, where control PHY and MAC data arereceived, decoded, and processed in step 412. Step 414 then utilizes thedecoded PHY and MAC data for IP stack processing, if frame-by-framebandwidth allocation changes were detected, at which point, in step 416,method 400 transmits data as determined by the scheduled new downlinkbandwidth allocation data. Method 400 then moves to step 406. If, instep 408, method 400 determines no downlink bandwidth allocation changeshave occurred then method 400 moves to step 418.

In step 418 method 400 bypasses MAC/IP Stack data access and allocatedbandwidth utilizing the same downlink bandwidth allocation as was usedin the previous frame. That is, method 400, at step 418, transmits dataas prescribed by the previous PHY allocations for the MHR clients suchthat MAC processing cycles are not changed and no changes to thescheduler occur. It will be understood that changes to the hierarchicalMHR scheduler may still occur (executed by the master MHR). Thus, PHYallocations for the MHR clients are unchanged from the previous frame.This eliminates MAC and IP Stack processing, which are much slower interms of processing time than the PHY processing. The results in anend-to-end user latency improvement. The one-way end to end latencyimprovement may be in the range of, for example, 5-50 ms. It will beunderstood by the skilled artisan that this is MAC/IP Stackimplementation dependent. In a simplified system, step 418 returns tostep 408 after completion. Optionally, method 400 moves to an idle modeprocess function starting at step 420.

In decision step 420, method 400 determines if an optional idle mode isinitiated, for example, by the hierarchical MHR. If idle mode is notinitiated, step 420 moves to step 426, see below. If in step 420 it isdetermined that idle mode will be initiated then step 420 moves to step422, which initiates idle mode. One example of steps 420 and 422 isslave MHR 104 receiving instructions to initiate idle mode for a setperiod of time or a set number of frames. Step 422 then moves to step424.

In decision step 424, method 400 determines if the set period of time orset number of frames has expired. If in step 424 method 400 determinesthat the set period of time or set number of frames has not expired step424 moves to step 427, otherwise method 400 moves to step 425. In step427 method 400 determines if a wake-up request has been received. If awake-up request has not been received method 400 moves to step 422,otherwise method 400 moves to step 410. If in step 424 method 400determines that the set period of time or set number of frames hasexpired, then step 424 moves to step 425.

In decision step 425, method 400 determines if idle mode should bereactivated. If it is determined in step 425 that idle mode should bereactivated, method 400 moves to step 422. If it is determined in step425 that idle mode should not be reactivated, method 400 moves to step410, as described above. Alternatively, method 400 may move to decisionstep 408.

Returning to method 400, moving from step 420 to step 426, whichdescribes method 400 entering an optional sleep mode processingfunction. In step 426, method 400 determines if a sleep mode is to beinitiated, based on the local requirements for transmission (e.g. databuffer size). In one example of step 426, slave MHR 104 determines thatno new PHY allocations have occurred, for example by determining that anassociated transmission data buffer is empty, for a predetermined numberof frames at which point the node places itself in sleep mode. If instep 426, method 400 determines that sleep mode is not to be initiated,then method 400 returns to step 408. If method 400 determines that sleepmode is to be activated, then method 400 moves to step 428.

In step 428 method 400 initiates sleep mode. One example of step 428 isslave MHR 104 placing itself in sleep mode. In an embodiment, initiatinga sleep mode includes switching off at least some of PHY and MACprocessing for purposes of power savings. Method 400 then moves to step430, where method 400 monitors PDFSCCh data to determine the presence ofa paging wake-up call request. In one example of step 430, slave MHR104, while in sleep mode, continues to process PHY data, e.g., PDFSCChdata, received from master MHR 102. Slave MHR 104 examines the receivedPHY data to identify a paging wake-up call request, which maybe in theform of a change to DL bandwidth allocation or may be a dedicatedwake-up signal.

Method 400 then moves to decision step 432, where method 400 determinesif a paging wake-up request was identified in step 430. If method 400,in step 432, determines that a paging wake-up request was identified instep 430 then method 400 moves to step 406, described above.Alternatively method 400 may move to step 406. In one example of step432, slave MHR 104 determines that a paging wake-up request has beenidentified and slave MHR 104 wakes from sleep mode and processes the IPStack. If in step 432 method 400 determines that no paging wake-uprequest was identified in step 430, then method 400 moves to step 428.

FIG. 5 shows one exemplary uplink bandwidth allocation feedback method500. FIG. 5 is best viewed in combination with FIGS. 1 and 2C. In method500, a slave MHR/pBS provides an uplink bandwidth allocation datarequest to the next hierarchical node in the system based on the statusof an uplink software buffer. Herein, a software buffer is a bufferhaving variable size. For example, slave MHR 104 may use this method toupdate its aggregated uplink bandwidth allocation data request based onuplink data received from pBS 108, 110 and RU 155.

In step 502 of method 500, a slave MHR/pBS is initialized and connectsto its hierarchical node, e.g., a master MHR. If the slave MHR/pBS haspreviously been initialized and connected to its hierarchical nodemethod 500 skips step 502. One example of step 502 is slave MHR 104establishing wireless communication with master MHR 102 during aninitialization process at start-up or during a communicationreestablishment process after communication loss. Method 500 then movesto step 504.

In step 504, method 500 monitors the uplink software buffer. One exampleof step 504 is slave MHR 104 monitoring its uplink software buffer 238to detect if slave MHR 104 has new aggregated uplink bandwidthallocation request data 239 stored in software buffer 238 from one ormore of pBS 108, 110, and RU 155. Some non-limiting examples ofdetecting a change include comparing current data with data from one ormore previous frames, monitoring a change in the size of software buffer238, and by monitoring a “change flag.” Method 500 then moves todecision step 506.

In decision step 506, method 500 determines if a change to the uplinksoftware buffer processed was detected in step 504. Some example of step506 is slave MHR 104 determining if software buffer 238 changed size, ifa “change flag” was activated, or if a comparison of current data 239 toold data 239 showed a difference between the two. If method 500determines that no change to the uplink software buffer occurred in step504, then method 500 moves to step 505 where method 500 indicates to thehierarchical node that there are no new uplink bandwidth allocationrequests. One example of step 505 is slave MHR 104 transmitting to themaster MHR 102 at least data 282 showing no change to uplink bandwidthallocation requests. For one example of the format of data 282 see Table3, below. Alternatively, slave MHR 104 may not transmit any data tomaster MHR 102 during a frame, which may indicate to master MHR 102 thatthere is no change to the uplink bandwidth allocation data request. Thisallows master MHR 102 to skip reading and processing bandwidthallocation headers of the uplink Ethernet headers and updating uplinkcontrol allocations. This is what is referred to herein as “fastsignaling,” a process which drastically reduces latency by reducingreading, processing, and writing steps. That is, fasting signalingallows a receiving device to process the minimum amount of data forpurposes of bandwidth allocation (uplink or downlink), thereby reducinglatency. Step 505 then moves to step 504. If method 500 determines thata change to the uplink software buffer has occurred, method 500 moves todecision step 508.

In step 508, method 500 determines if the device is in sleep mode. Ifmethod 500 determines the device is in sleep mode method 500 moves tostep 510, where a wake-up request is executed. Step 510 then moves tostep 512 where method 500 registers uplink feedback data in the softwarebuffer, then moves to step 514 where method 500 updates uplink bandwidthallocation request data and uplink fast feedback data stored in memory,e.g., data 280 and 282, respectively. If, in step 508, method 500determines that the device is not in sleep mode, then method 500 movesto step 512 where method 500 registers uplink feedback data, then movesto step 514 where method 500 updates uplink bandwidth allocation requestdata and uplink fast feedback data stored in memory. One example ofsteps 508, 510, 512, and 514 is slave MHR 104 processing a wake-up call,registering new uplink feedback data 239, and updating uplink bandwidthallocation request data 280 and uplink fast feedback data 282 stored inmemory 220 based on the registered data 239. One example of steps 512and 514 is slave MHR 104 updating uplink bandwidth allocation requestdata 280 and uplink fast feedback data 282 stored in memory 220 based onthe registered data 239. Method 500 then moves to step 515.

In step 515 method 500 transmits updating uplink bandwidth allocationrequest data 280 and uplink fast feedback data 282 to the master MHR forincorporation into step 410 of method 400, FIG. 4. In one example ofstep 515 slave MHR 104 transmits updating uplink bandwidth allocationrequest data 280 and uplink fast feedback data 282 every transmissioncycle. In another example of step 515 slave MHR 104 only transmitsupdating uplink bandwidth allocation request data 280 and uplink fastfeedback data 282 when there is a change to the data. In this example,if there are no changes to the uplink allocation feedback data then nouplink allocation feedback data is sent. Method 500 then moves to step504, described above.

Table 1, below, shows one exemplary downlink look-up table for fastsignaling, which shows signaling used in downlink and uplink processingand describes a non-limiting case of 16 slaves attached to one masternode.

Table 1 includes three columns, a “Word (hex)” column, a “User Name”column, and a “Comment Word (H)” column. The hexadecimal notion in the“Word (hex)” column identifies the user (shown in the “User Name”column) and identifies if any changes have occurred to that user'sdownlink bandwidth allocation and/or uplink bandwidth allocation. Forexample, 0x00 through 0x03 cover changes to Slave 00's downlink (0x00through 0x01) and uplink bandwidth allocation (0x02 through 0x03), 0xF0through 0xF3 cover changes to Slave 04's downlink and uplink bandwidthallocation, etc. It will be understood that the signal scheme shown inthe tables below are only examples of possible methodologies and othermay be utilized without departing from the scope herein.

TABLE 1 Downlink/Uplink Fast Signaling Allocation Table Word User (hex)Name Comments Word 0x00 Slave 00 0: no DL BW allocation change; 0x01Slave 00 1: DL BW allocation change 0x02 Slave 00 0: no UL BW allocationchange; 0x03 Slave 00 1: UL BW allocation change . . . 0xF0 Slave 04 0:no DL BW allocation change; 0xF1 Slave 04 1: DL BW allocation change0xF2 Slave 04 0: no UL BW allocation change; 0xF3 Slave 04 1: UL BWallocation change . . . 0x3C Slave 15 0: no DL BW allocation change;0x3D Slave 15 1: DL BW allocation change 0x3E Slave 15 0: no UL BWallocation change; 0x3F Slave 15 1: UL BW allocation change

Each hierarchical slave is associated with a master MHR and has 4entries in its Downlink/Uplink Fast Signaling Allocation Table, Table 1.Table 1 summarizes downlink (DL) and uplink (UL) PHY allocations on aframe by frame basis. UL subsections reflect the information receivedfrom UL feedback fast signaling channel and represents a confirmation ofUL allocation requests made by, for example, slave MHR 104.

The number of entries in Table 1, represented in the equation below as‘W’, is equal to four times the number of users (‘n’). Note that in thepresent embodiment n≦16, although ‘n’ may be increased, for example, to32 or 64 in other embodiments. Thus:

W=n*4,  (1)

where:W=the number of downlink lookup table entries, andn=number of users.

A user value set, ‘w_(dl)’, is described in Table 2, below. The uservalue set describes the entries in the DL Look-Up table for each user,which describes the behavior of a user in terms of DL and UL fastsignaling changes. The user value set ‘w_(dl)’ relates to the “CommentsWord” shown in FIG. 1, above.

TABLE 2 W_(dl) no DL allocation change DL allocation change no ULallocation change UL allocation change

If a slave device determines, during the decoding of the Downlink/UplinkFast Signaling Allocation data as shown in Table 1, that there is achange in the downlink and/or uplink bandwidth allocation then the slavedevice will decode the related PHY/MAC/IP Stack data to retrieve the newDL and/or UL bandwidth allocation data. If no change is determinedduring the decoding of the Downlink/Uplink Fast Signaling AllocationTable then the slave device will utilize the same Dl and UL bandwidthallocation as was utilized in the previous frame.

If a slave device detects no downlink or uplink bandwidth allocationchange, the respective device processes the same PHY bandwidthallocation as was processed in the last frame or set of frames. Thus, aslave device will process the respective bandwidth allocation muchfaster, for example, by 5-50 ms faster depending on implementation. Thisdramatically reduces the one way end-to-end user packets latencyaccordingly.

As described in method 400, a device may be sent into idle mode. In anembodiment, idle mode may be initiated by the detection of a bandwidthallocation pattern. For example, a device which detects a bandwidthallocation pattern sequence for a given user, for example, “0x00/0x03”for a predetermined number of frames may switch to idle mode. A devicein idle mode transmits no RF energy to its users, thus saving energy andreducing the intra-cell and inter-cell interference. In addition, adevice in idle mode may continue to monitor the DL Lookup Table of thehierarchical MHR master, transmitted over the PDFSCCh. A device in idlemode may be returned to active mode via another designated sequence orwhen a change to a DL or UL bandwidth allocation is detected.

Table 3, below, shows one exemplary Uplink MHR Feedback Table for fastprocessing of one or more uplink bandwidth allocation change requests.Table 3 describes signaling used in uplink feedback processing andrepresents one non-limiting case of 16 slaves attached to one masternode. Similar to Table 1, Table 3 includes a “Word (hex)” column and a“User Name” column. Table 3 differs from Table 1 in that Table 3replaces the “Comment Word (hex)” column of table 1 with a “Comments(CR: Change Request)” column. The hexadecimal notion in the “Word (hex)”column identifies a user, shown in the “User Name” column and alsoidentifies any change to the uplink bandwidth allocation for that useror if a wake-up request or a sleep request has been sent for that user.For example, 0x00 through 0x03 cover changes to Slave 00's uplink (0x00through 0x01) and wake-up request (0x02), and sleep request (0x03).

TABLE 3 Uplink MHR Feedback Table Word User Comments (H) Name (CR:Change Request) 0x00 Slave 00 0: no UL BW allocation CR; 0x01 Slave 001: UL BW allocation CR 0x02 Slave 00 0: wake-up request 0x03 Slave 00 1:sleep request . . . 0xF0 Slave 04 0: no UL BW allocation CR; 0xF1 Slave04 1: UL BW allocation CR 0xF2 Slave 04 0: wake-up request 0xF3 Slave 041: sleep request . . . 0x3C Slave 15 0: no UL BW allocation CR; 0x3DSlave 15 1: UL BW allocation CR 0x3E Slave 15 0: wake-up request 0x3FSlave 15 1: sleep request

Each hierarchical slave is associated with a master MHR and has 4entries in its Uplink MHR Feedback Table, Table 3. The number of UplinkMHR Feedback Table entries (‘W’) is equal to four times the number ofusers (‘n’), similar to Table 1 described above. Note that in thepresent embodiment n≦16, although ‘n’ may be increased without departingfrom the scope herein. Thus, as similarly described above for equation(1), W=n*4, where: W=the number of downlink lookup table entries andn=number of users.

A user value set, ‘w_(ul)’ described in Table 4 below, for Uplink MHRFeedback Table differs from that of that of the Downlink/Uplink FastSignaling Allocation Table. While the Uplink MHR Feedback Table reflectsthe status of the slave MHR device uplink software buffer andaccordingly the request for change in the uplink PHY allocation, themaster MHR, e.g., master MHR 102, may confirm the received feedback bybroadcasting the changes in uplink PHY allocation requests.

TABLE 4 W_(ul) no UL BW allocation CR UL BW allocation CR wake-up flagsleep request

When a master MHR detects an uplink bandwidth allocation change request(CR) transmitted by a client device (e.g., Slave 00, RU 150, etc.), themaster MHR device decodes the associated PHY/MAC information to processthe related allocation size and location. The master MHR then passesthis information to the master MHR scheduler to schedule resource forthe requesting client device.

If no uplink bandwidth allocation change request is detected from aclient device then the master MHR will not change the related uplinkbandwidth allocation for that client. One exception may be when thescheduler can't comply with this request due to conflicts associatedwith bandwidth allocation to neighboring devices. Similarly the masterMHR may not change downlink bandwidth allocation for that client due toconflicts. Is such cases, changes to uplink and downlink bandwidthallocations may be pushed to the next frame.

PDFSCCh and PUFFCh PHY Support

The Downlink/Uplink Fast Signaling Allocation Table entries, also calledthe downlink lookup table entries, are transmitted using a ConstantAmplitude Zero Autocorrelation (CAZAC) function. One example of such aCAZAC function is a simplified form of the Zadoff-Chu (ZC) function,described below:

$\begin{matrix}{{x_{u} = {\exp \lbrack {{- j}\frac{\pi \; {{un}( {n + 1} )}}{N_{ZC}}} \rbrack}},{0 \leq n \leq N_{ZC}}} & (2)\end{matrix}$

Where x_(u) is the function value,j is the complex number (−1)^(1/2),u is the ZC sequence index,n is the position of each root Zadoff-Chu sequence, andN_(ZC) is the prime length, which is a positive integer, in order tominimize the unwanted cross-correlation products of the ZC function.

Here we utilize the Chu sequence, which is a special case of theZadoff-Chu sequence where q=0:

$\begin{matrix}{{x_{u} = {\exp \lbrack {{- j}\frac{\pi \; {{un}( {n + 1} )}}{N_{ZC}}} \rbrack}},{0 \leq n \leq N_{ZC}}} & (3)\end{matrix}$

The output sequence of equation (3) is a complex-valued column vectorthat contains the u^(th) root Zadoff-Chu sequence of length N_(ZC).

The ZC function is one preferred method for this type of signaling dueto its excellent peak to average power ratio (PAPR), auto-correlationproperties, and cross correlation products of the same root.

The calculation of prime length N_(ZC) is dependent on the length of thesequence, that is, it is dependent on the subframe/frame length for thespecific modulation scheme and frame structure utilized. The relatedlink budget for this signaling channel may be given by:

P _(Rx) =P _(Tx) −PL+G _(ANT) _(Tx) +G _(ANT) _(Rx) +10 log₁₀ N_(ZC),  (4)

where:

-   -   P_(Rx)=Received Rx Power for the Physical Fast Allocation        Channel (PFACh)    -   P_(tx)=Transmitted Tx Power for the Physical Fast Allocation        Channel (PFACh)    -   PL: Path Loss ([dB])    -   G_(ANT) _(Tx) , G_(ANT) _(Rx) : Tx and Rx antenna gains, and    -   Nzc: the length of the pseudo-chirp sequence (Zadoff-Chu in this        case).

The ZC sequence length is limited by the related inter-carrier spacingand the supporting LO performance (phase noise), since the longer the ZCsequence, the smaller is the inter-carrier space, though the higher isthe LO phase noise impact. For example, with N_(ZC)=811 a chirp sequencegain of 29.1 dB is produced.

Herein the Zero Correlation Zone (ZCZ) is defined as the minimum bandvalue covering the maximum delay spread. The cyclic shift (N_(CS)) isrepresented by ZC sequences phase-shifted from a single root, providingorthogonality between sequences. The cyclic shift is,

$\begin{matrix}{N_{CS} \geq {\lbrack {( {{\frac{20}{3}r} - \tau} )\frac{N_{ZC}}{T_{SEQ}}} \rbrack + {{n_{g}\lbrack 1\rbrack}.}}} & (5)\end{matrix}$

In one example with a cell radius of r=0.5 km, a 28 GHz delay spreadsuch that t=0.7 ms, and T_(SEQ)=400 ms, N_(ZC)=811, n_(g)=25, N_(CS)=4.For N_(ZC)=811, results in N_(CS)≦202 possible cyclic shifts for oneroot available. This is more than sufficient when a D-FFT=64 isemployed. This also could support a D-FFT 128, thus enlarging the amountof client devices to 32.

PDFSCCh and PUFFCh—PHY Support

FIG. 6 shows frame (k) 600 of 2 milliseconds (ms) divided into four (4)subframes k1, k2, k3, and k4, each of 0.5 ms. Frame (k) may be thesimilar or different from frame (k) 352 of FIG. 3. For sake ofsimplicity and clarity of illustration only PHY resource 610's block m612 of subframe k2 604 is shown in detail. The detailed view of subframek2 604's block m 612 shows an implementation of a Zadoff-Chu based onN_(ZC)=811 resulting in 811 Zadoff-Chu subcarriers 640, scZC00-sc ZC810.28 additional subcarriers are also used as guard subcarriers, 14subcarriers 630 above and 14 subcarriers 632 below. Without losinggenerality other frame structures, different number of frames, andsymbols/subframe, may be employed.

In the example provided above Nzc=811 was chosen for the ZC function. Inorder to avoid any cross carrier interference with the adjacent PHYsubcarriers (e.g. OFDM, SC_FDMA or other modulations employed by thebasic PHY) guard subcarriers are employed (14 on each side of the ZCsubcarriers). Without losing generality other Zadoff-Chu function primenumber orders could be chosen could be employed.

In an embodiment six (6) cyclic shifts, located on phase shifts largerthan the related Zero Correlation Zone, are selected: in one example ZCsubcarriers 51, 232, 341, 457, 557 and 767 provide the good crossauto-correlation products for the respective RF channel. In the presentembodiment subcarrier scZC00 and subcarrier scZC810 are excluded. Aslave device associated with a MHR will look for these six (6) specificsubcarriers in the order specified above to decode the DL Look-Up Table‘W’, which is a 6 bit word. Decoding a 6 bit word length DL Look-UpTable requires only 1-3 ms as compared to the 5-50 ms required to decodea the information carrier over the PHY/IP Stack. Therefore each one ofthe entries in the DL Look-up and UL Feedback tables, for up to 16 slavedevices could be encoded using the above ZC function model. Withoutlosing generality, selecting 8 ZC roots (instead of 6, as exemplifiedabove) may increase the number of supported slave devices to 64.

Changes may be made in the above methods and systems without departingfrom the scope hereof. It should thus be noted that the matter containedin the above description or shown in the accompanying drawings should beinterpreted as illustrative and not in a limiting sense. The followingclaims are intended to cover all generic and specific features describedherein, as well as all statements of the scope of the present method andsystem, which, as a matter of language, might be said to fall therebetween.

What is claimed is:
 1. A fast downlink bandwidth allocation systemconfigured with a first level hierarchical device in a multi-hop relayhierarchical network formed of at least a first, a second, and a thirdlevel node, comprising: a non-transitory memory configured to store anallocation data, a first uplink fast feedback data (UFFD) associatedwith a previous data frame, and an uplink bandwidth allocation requestdata; an uplink bandwidth module for conditionally processing the uplinkbandwidth allocation request data to produce a processed uplinkbandwidth allocation data which is written to the allocation data in thenon-transitory memory; a PHY module configured to provide conditionalinstructions to the uplink bandwidth module to processing the uplinkbandwidth allocation request; a scheduler configured to schedulebandwidth allocation for the second and third level nodes based on theallocation data; and a processor in communication with thenon-transitory memory, the uplink bandwidth module, the PHY module, andthe scheduler for cooperating in bandwidth allocation computationalprocesses.
 2. The system of claim 1, wherein the uplink bandwidthallocation request data further comprises a second UFFD associated withthe current data frame.
 3. The system of claim 2, the PHY module furthercomprises a comparator configured to take as inputs the first UFFD andthe second UFFD and produce a difference result which describesdifference between the first and second UFFD.
 4. The system of claim 3,wherein the PHY module is configured to participate in providing theconditional instruction for decoding the uplink bandwidth allocationrequest to the uplink bandwidth module, wherein the conditionalinstructions are a function of the difference result.
 5. The system ofclaim 4, wherein the conditional instructions instructs the uplinkbandwidth module to process the uplink bandwidth allocation request dataif there is a difference between the first and second UFFD.
 6. Thesystem of claim 4, wherein the difference result based conditionalinstructions instructs the uplink bandwidth module to not process theuplink bandwidth allocation request and to utilize the previousallocation data for the next bandwidth allocation.
 7. The system ofclaim 1, wherein uplink bandwidth allocation request data is receivedfrom at least a plurality of second level nodes.
 8. The system of claim7, wherein each of the plurality of second level nodes receives a thirdlevel uplink bandwidth allocation request data from at least one thirdlevel node.
 9. The system of claim 8, wherein one or more second levelnodes are selected from the group consisting of a slave multi-hop relay,a pico-base station, and a remote unit.
 10. The system of claim 8,wherein one or more third level nodes is selected from the groupconsisting of a slave multi-hop relay, a pico-base station, and a remoteunit.
 11. A fast downlink bandwidth allocation system configured with asecond level node in a multi-hop relay hierarchical network formed of atleast a first, the second, and a third level node, comprising: anon-transitory memory configured to store a bandwidth allocation data, areceived bandwidth allocation data, and a first downlink fast feedbackdata (DFFD) associated with a previous data frame; a downlink bandwidthmodule for processing the received bandwidth allocation data to producea processed bandwidth allocation data which is written to the bandwidthallocation data in the non-transitory memory; a PHY module configured toprovide conditional instructions to the downlink bandwidth modulerelated to processing the received bandwidth allocation data; ascheduler configured to schedule bandwidth allocations for at least thethird level nodes based on the bandwidth allocation data; and aprocessor in communication with the non-transitory memory, the downlinkbandwidth module, the PHY module, and the scheduler for cooperating inbandwidth allocation computational processes.
 12. The system of claim11, wherein the received bandwidth allocation data is one or both ofdownlink received bandwidth allocation data and uplink receivedbandwidth allocation data.
 13. The system of claim 11, wherein thereceived bandwidth allocation data includes a second DFFD associatedwith a current data frame which conveys information regarding changes inthe received bandwidth allocation data.
 14. The system of claim 13,wherein the PHY module further comprises a comparator for comparingfirst DFFD and the second DFFD to determine if a change has occurred inthe bandwidth allocation data between the current bandwidth allocationand a previous bandwidth allocation.
 15. A method for fast downlinkbandwidth allocation in a multi-hop relay hierarchical network,comprising: accessing a first downlink fast feedback data (DFFD) storedin a non-transitory memory and associated with a previous bandwidthallocation data from a previous data frame; receiving of an encodeddownlink bandwidth allocation data associated with the current framefrom a master multi-hop relay; receiving a second DFFD associated withthe current frame from a master multi-hop relay; accessing the secondDFFD associated with the current data frame; and comparing the first andsecond DFFD to determine a difference between the current and theprevious downlink bandwidth allocation data.
 16. The method of claim 15,further comprising the step of determining there is no differencebetween the first and second DFFD.
 17. The method of claim 16, furthercomprising the step of transmitting the previous bandwidth allocationdata to one or more lower level nodes in the multi-hop relayhierarchical network based on the determination that there is nodifference between the first and second DFFD.
 18. The method of claim15, further comprising determining there is difference between the firstand second DFFD.
 19. The method of 18, further comprising decoding theencoded downlink bandwidth allocation data and transmitting the decodeddownlink bandwidth allocation data to one or more lower level nodes inthe multi-hop relay hierarchical network based on the determination thatthere is difference between the first and second DFFD.
 20. The method ofclaim 15, wherein the encoded downlink bandwidth allocation data and thesecond DFFD are received as a single data package and accessing thesecond DFFD associated with the current data frame comprises decodingonly the portion of the single data package that contains the secondDFFD.